%\begin{Anàlisi i Disseny}

\setcounter{section}{0}

\section{Introducció}

Després d'haver avaluat tantes alternatives es va arribar a la conclusió que es realitzaria el següent: 

\begin{itemize}

\item Utilitzar les biblioteques de mapsforge per a cobrir algunes de les funcionalitats bàsiques de les biblioteques del projecte.

\item Expandir les biblioteques de mapsforge per a cobrir la resta de les funcionalitats que no estaven garantides per l'ús d'aquestes biblioteques i oferir a la comunitat de mapsforge la possibilitat d'integrar aquestes funcionalitats en el projecte i contribuir-hi així.

\item Dissenyar una interfície perquè aquesta biblioteca resultant pugui ser utilitzada pel ZamiaDroid per a mostrar els mapes i aportar noves capacitats.

\item Dissenyar una aplicació (erdapfel) fent servir Java i  l'SDK d'Android, que permeti mostrar els mapes i provar les funcionalitats de la biblioteca.

\item Dissenyar una ``façana de SL4A'' perquè les principals funcionalitats de la biblioteca siguin accessibles des dels llenguatges de ``scripting'' de SL4A.

\end{itemize}

Potser un dels factors claus per l'elecció de mapsforge va ser el fet que a la documentació del projecte existia una proposta per a incloure suport per a KML, que s'havia considerat interessant per la comunitat de desenvolupadors, però desestimat per culpa de restriccions purament temporals (la podeu consultar a l'\hyperlink{annex-mapsforge-issue-kml}{annex}).

\paragraph{}
A banda d'això, el fet de no trobar una manera clara per desenvolupar les biblioteques en llenguatges alternatius que després en garantís la plena utilitat, també hi va ajudar.

\section{Especificació de les biblioteques}

Les biblioteques resultants d'aquest projecte havien de proporcionar les següents funcionalitats:

\subsection{Renderitzat de mapes de fonts osm}

L'elecció de mapsforge ens garantia el suport de mapes de fons osm de manera ``nativa''. En aquest apartat, doncs, es contava aprofitar les característiques de la biblioteca.

\paragraph{}
Mapsforge permet descarregar-se ``tessel·les'' (tiles) generades amb mapnik a partir de les dades de OpenStreetMap, des dels servidors de tiles del mateix OpenStreetMap o des del servidor d'OpenCycleMap. Es pot estendre per mostrar tessel·les d'altres servidors, si es vol, però per defecte implementa aquests dos.

\paragraph{}
Ara bé, a més de poder mostrar mapes generats amb dades osm (que és un dels objectius del projecte), també es pretenia permetre llegir directament els formats .osm, que és un xml amb les dades ``raw'' d'OSM, o .pbf, que és un format binari també amb aquestes dades.

\paragraph{}
En aquest cas el suport de mapsforge no és tant immediat, però això es comentarà a l'apartat de mapes fora de línia, ja que, encara que siguin ``fonts OSM'' s'han considerat formats ``fora de línia''.

\subsection{Renderitzat de mapes fora de línia}

Un factor determinant a l'hora d'escollir Mapsforge com a base de les biblioteques va ser perquè aportava suport per a mapes ``offline''.

\paragraph{}
Durant l'estudi tecnològic, però, no es va veure exactament quin era el mecanisme per a proporcionar aquest suport.

\paragraph{}
Pel que sembla la manera usual d'aportar aquesta funcionalitat en les aplicacions que fan ús de mapsforge es processar les dades OSM del mapa desitjat amb un mòdul específic de l'eina Osmosis creat a tal efecte per la gent de mapsforge (el mapfileWriter).

\paragraph{}
Fent ús d'aquest mòdul d'osmosis es poden processar dades de diverses fonts OSM (ja sigui en el format XML d'OpenStreetMap, el format binari, etc.) i generar mapes en el format de mapa que després mapsforge llegeix i amb el qual treballa.

\paragraph{}
Com es pot veure això implica un pre-procés de les dades abans de que mapsforge les mostri, que no es va detectar durant l'estudi tecnològic de l'aplicació, i ha resultat ser una inconveniència imprevista.

\paragraph{}
Normalment aquest pre-procés es realitza en un ordinador personal i els mapes es transfereixen als dispositius mòbils que requereixin les dades, o alternativament el pre-procés es realitza en un servidor que rep la petició de l'usuari del dispositiu per xarxa i transfereix el mapa en el format propi de mapsforge.

\paragraph{}
Cap de les dues opcions era plenament satisfactòria per la nostra visió del projecte, així que es va estudiar la possibilitat de portar l'eina Osmosis i el corresponent mòdul de mapsforge a Android perquè aquest a fase de pre-procés dels mapes pogués ser duta a terme en el mateix dispositiu mòbil i així cobrir aquesta funcionalitat sense alterar el funcionament usual de la biblioteca mapsforge.

\subsubsection{Adaptació d'osmosis a Android}

Osmosis és una eina escrita en Java per processar dades d'OSM. És una eina molt versàtil i extensa consistent en un seguit de components connectats que poden encadenar-se i produir operacions complexes. Ha estat dissenyada de tal manera que afegir-hi nous components sigui senzill.

\paragraph{}
Tal com s'ha dit anteriorment, és l'eina que es fa servir per tractar dades extretes d'OSM i convertir-les en el format de mapes propi de mapsforge.

\paragraph{}
La necessitat de processar les dades amb aquesta eina fora del dispositiu Android trencava la filosofia de treball que es pretenia aconseguir idealment amb el projecte (i per tant les biblioteques que s'estan especificant).


\paragraph{}
Davant d'aquest problema es plantejaven dues vies d'actuació:

O bé es modificava la biblioteca de mapsforge per a acceptar aquests formats de manera similar al que es tenia previst fer amb els formats KML i GML, o bé s'intentava mantenir la metodologia de treball plantejada per mapsforge, però adaptant-la a les necessitats particulars d'aquest projecte intentant aportar els mitjans per realitzar el mateix pre-procés que es faria en un servidor o ordinador personal, al telèfon mòbil.

\paragraph{}
L'opció de modificar les biblioteques de mapsforge es va veure exagerada. A més de comportar certa redundància, semblava molt invasiva i dificultava la possible integració posterior de les modificacions al projecte mapsforge.

\paragraph{}
Així que es va creure que l'opció més adient, menys problemàtica i amb possibilitats d'èxit era fer un port d'osmosis a la plataforma Android.

Aquest ``port'' va comportar certes dificultats tècniques que s'explicaran a l'\hyperlink{implm-mapfile-writer}{apartat d'implementació}, però teòricament era viable.

\paragraph{}
A més de les dificultats tècniques, afegia algunes contrapartides inherents, com són un previsible increment del temps que el pre-procés trigaria al dispositiu Android, o la reducció de la vida de la bateria del telèfon al realitzar els càlculs. Però es va considerar que aquestes contrapartides eren assumibles, ja que aquest seria un procés que es realitzaria esporàdicament.

\subsection{Suport per a GML \& KML}

Pel suport dels formats GML i KML, la cosa era diferent, ja que, per començar la biblioteca mapsforge no proporcionava cap mitjà per a permetre'n la visualització (ni tan sols un d'inconvenient com en el cas anterior).

\paragraph{}
A més, tal i com podeu veure a l'\hyperlink{annex-mapsforge-issue-kml}{annex}, l'existència d'una proposta d'afegir aquestes funcionalitats a mapsforge, feia que al mateix temps que es cobrien les necessitats del present projecte, es cobrien també els requeriments del projecte mapsforge.

\paragraph{}
Això, al nostre entendre justificava molt més la modificació de les biblioteques de mapsforge.

\paragraph{}
Al plantejar l'``expansió'' de les capacitats de mapsforge calia considerar molt bé, però, com plantejar-ho.

Resultava evident que un dels passos era afegir-hi la capacitat d'interpretar documents GML i KML (o parsejar-los), i també que calien funcionalitats per a mostrar-los.

Una de les maneres que es podria haver decidit per tal de mostrar els documents KML/GML, hauria pogut ser un procés semblant a l'existent per carregar fitxers de mapes propis de mapsforge (.map). És a dir crear el que dins el projecte hauria estat alguna subclasse de ``mapgenerator''.

\paragraph{}
En aquest punt es va decidir, però, no tractar els documents GML i KML com a fitxers de ``mapes'' pròpiament dits, sinó com a fitxer de ``capes''.

\paragraph{}
M'explicaré: malgrat que un mapa no és més que un conjunt de capes, en el projecte mapsforge es fa una distinció entre un fitxer que conté un mapa sencer i les capes que posteriorment s'hi poden anar afegint a sobre. Els fitxers KML es fan servir sobretot per a exportar capes i no tant ``mapes'' sencers.

\paragraph{}
El cas d'ús que la comunitat de mapsforge esperava cobrir aportant aquesta nova funcionalitat era que un usuari exportes d'algun o altre programa extern una capa en KML, i la pogués carregar sobre un mapa de mapsforge.

%INTERROGANT
%\paragraph{}
%Aquesta distinció entre els conceptes de ``mapa'' i ``capa'' resulta una mica arbitrària i difusa en aquest punt, però és important tenir-la en compte pel que es podrà comprovar a l'apartat d'implementació, i es va fer així perquè és el que esperava la comunitat de mapsforge, i tampoc no suposava cap problema per al nostre projecte, ja que l'aplicació que es fes podia prescindir d'aquesta terminologia en un nivell ``superior'' i tractar els fitxers KML/GML com calgués (és a dir, el fet que a la biblioteca de mapsforge estesa un fitxer KML fos tractat com a una capa, no ens privava de pintar un ``mapa sencer'' a partir d'ell).

\paragraph{}
Així per a garantir el suport a KML i GML, es va decidir implementar ``parsers'' de GML i de KML i estendre els Overlays (capes) de mapsforge, per intentar fer un ``mimetisme'' amb els diferents elements ja existents a la biblioteca mapsforge, i que la seva utilització fos pràctica i similar a la que ja s'estava fent servir, i no fos traumàtica per a desenvolupadors avesats a l'API d'Overlays de mapsforge.

\paragraph{}
Això va comportar greus problemes quan mapsforge va remodelar radicalment aquesta API en una actualització de la biblioteca, tal i com s'explicarà amb meś detall \hyperlink{impl-conclusions-mapsforge}{més endavant}.

\paragraph{}
Per altra banda, la decisió d'implementar un ``parser'' de GML/KML va sorgir després de cercar extensivament implementacions ja existents sense èxit.

Sembla a ser que tot i que KML i GML són un estàndards força estesos basats en XML, no existia cap solució implementada que poguéssim trobar i que fos adient per a  ambdós formats.

\section{Integració amb ZamiaDroid}

Per a la integració amb ZamiaDroid, es van tenir en compte diverses possibilitats.

El primer que es va considerar va ser, tenint en compte que la API de mapes de Google que utilitza ZamiaDroid és molt similar a la API de mapsforge, fer les modificacions pertinents perquè ZamiaDroid fes servir la nostra expansió de mapsforge en comptes de la biblioteca de Google.

Aquesta solució no era prou bona perquè implicava alguns problemes:

\begin{itemize}
        \item Mapsforge no garantia la total equivalència entre la seva API i la de Google, cosa que vol dir que canviar una biblioteca per l'altre no era immediat, sinó que podia significar una gran modificació del codi de Zamia.

        \item Necessitat de fer una branca alternativa en el desenvolupament de ZamiaDroid per a realitzar aquesta integració, i possible dificult de la posterior ``mescla'' de branques degut a la evolució continua de Zamia i a l'alta volatilitat de les parts que treballen amb la API de mapes (que són moltes i molt poc estables).

        \item Mantenir el suport per a la utilització dels mapes de Google era un punt a favor per l'equip de Zamia, i aquesta solució implicava prescindir-ne.
\end{itemize}

Així que es va descartar en favor d'una opció que permetés la coexistència d'ambdós biblioteques de mapes.

\paragraph{}
Per garantir aquesta coexistència es va considerar la possibilitat d'incloure la biblioteca estesa de mapsforge a dins del ZamiaDroid. Però el sistema d'herència de Java dificultava molt el procés.

\paragraph{}
Tant l'API de mapes de google com la de mapsforge segueixen la filosofia d'Android d'integrar funcionalitats als programes mitjançant herència. És a dir, que per fer servir un mapa s'espera que s'hereti de la classe de mapes que proporciona la API (qualsevol de les dues) i es modifiqui al gust i/o necessitats de l'aplicació que s'està fent.

\paragraph{}
Això no només succeeix amb la classe MapView, sinó amb la pràctica totalitat de les classes que Zamia fa servir per treballar amb mapes (GeoPoint, Overlay, etc.).

\paragraph{}
I Java no permet herència múltiple, així que la integració amb Zamia per aquesta via suposava una duplicació de codi gairebé idèntic exageradament gran que no agradava ni als desenvolupadors de Zamia ni als del present projecte.

\paragraph{}
Es va mirar de dissenyar una jerarquia de classes que permetés aquesta integració de manera neta (sense haver de reescriure gairebé el mateix codi per a les dos versions de la biblioteca)\TODO{annexa la fumada?}, però aquesta estructura va resultar d'una complexitat elevada degut al gran nombre de classes que intervenien, i amb pocs beneficis. Així que es va considerar que no aportava netedat al projecte ans al contrari.

\paragraph{}
Finalment es va trobar una alternativa que comportava una modificació molt menys intrusiva de Zamia i aportava totes les funcionalitats que es requerien.

\paragraph{}
Aquesta alternativa va ser emprar les capacitats ja existents de ZamiaDroid per a exportar mapes en format KML junt amb el disseny d'una interfície entre el ZamiaDroid i l'aplicació de visualització de mapes erdapfel.

\paragraph{}
Fent servir la comunicació entre intents estàndard de la plataforma Android i KML com a suport de dades ZamiaDroid pot cridar l'aplicació de visualització erdapfel quan es vulgui visualitzar qualsevol dada de Zamia (ja sigui una citació concreta, com una selecció d'aquestes o un recorregut, etc.). 

\paragraph{}
Erdapfel fa servir la biblioteca estesa de mapsforge, i, per tant, permet tant la càrrega de GML/KML com la possibilitat de treballar fora de línia. I mitjançant els mateixos intents es pot comunicar a erdapfel quin comportament ha de tenir quan l'usuari interactua amb el mapa (què cal fer quan es pressiona una citació, etc.) que en el nostre cas concret serà enviar dades de la interacció i retornar el control a ZamiaDroid.

\paragraph{}
Aquesta interacció s'ha concebut de manera que sigui prou genèrica com perquè qualsevol aplicació que ho desitgi en pugui fer ús (no necessàriament ZamiaDroid).

\paragraph{}
A continuació es pot veure un esquema conceptual d'aquesta interacció:

\begin{figure}[ht]
  \centering
        \includegraphics[width=0.8\textwidth]{misc/esquema_interaccio_erdapfel_zamia.eps}
  \caption{Interacció Zamia erdapfel.}
\end{figure}

\paragraph{}
Com a contrapartida, aquest mètode podria limitar la interacció que pot tenir l'usuari amb el Zamia, ja que afegeix un estrat entre la comunicació del Zamia i l'usuari.

\section{Funcionalitats de l'aplicació erdapfel}

A part de demostrar les funcionalitats abans mencionades de la biblioteca estesa de mapsforge, erdapfel havia de permetre la integració amb ZamiaDroid per ajudar en la visualització. Així que erdapfel és una mena de visor avançat de mapes pensat perquè pugui ser cridat des d'una aplicació externa, o pel seu funcionament autònom. Aquestes són les seves funcionalitats principals:

\begin{itemize}
        \item Visualitzar mapes de fonts osm en línia
        \item Obrir mapes fora de línia
        \item Obrir fitxers KML i GML
        \item Generar elements geomètrics (punts i polígons)
        \item Realitzar mesures aproximades de distàncies i àrees sobre el mapa. 
        \item Guardar els elements geomètrics generats.
        \item Permetre a l'usuari gestionar els fitxers generats i els fitxers a visualitzar de manera gràfica.
\end{itemize}

\paragraph{}
També havia de permetre la invocació com a ``Intent'' a més de la invocació autònoma de l'aplicació, i acceptar paràmetres per tal de configurar-ne l'execució al fer-ho.

\paragraph{}
Les ``Activities'' que es van pensar per l'aplicació doncs van ser:

\begin{itemize}
        \item Mapa/Activity principal
        \item Pantalla de configuració
        \item Pantalla de selecció de fitxers
\end{itemize}

\paragraph{}
Tant la creació d'elements geomètrics com les mètriques es prendrien sobre el mapa de la pantalla principal directament.

\paragraph{}
Per gestionar els mapes es va pensar en una interfície similar a la d'un navegador de fitxers.

\paragraph{}
I per facilitar la utilització de l'aplicació i no sobrecarregar-ne la pantalla principal del mapa també es necessitava un menú de configuració, per definir paràmetres per defecte, temes d'estil, etc.

%\subsection{mapFileWriter4And}

\section{Disseny de l'aplicació erdapfel}

El disseny d'aplicacions amb l'SDK d'Android està força condicionat per l'arquitectura d'aquest sistema, així que no es permet gaire llibertat en aquest aspecte (com podeu comprovar llegint aquest article\cite{bib-mvc-android}). Però per altra banda si que es dona molta llibertat i facilitat en el disseny d'interfícies d'usuari. 

Aquest apartat és per mostrar aquest disseny d'interfícies d'usuari (no el disseny de l'arquitectura de l'aplicació en si, ja que aquest és el genèric emprat en totes les aplicacions Android).

A continuació es mostraran els prototips de disseny per a les pantalles de l'aplicació erdapfel.

\subsection{Pantalla principal i de mapes}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/erdapfel_prototype_main.eps}
        \caption{Prototip pantalla principal d'erdapfel.}\label{fig-erdapfel_prototype_main}
\end{figure}

\subsection{Pantalla de selecció de fitxers}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/erdapfel_prototype_filepicker.eps}
        \caption{Prototip pantalla de selecció de fitxers d'erdapfel.}\label{fig-erdapfel_prototype_filepicker}
\end{figure}

\subsection{Pantalla de configuració}

\begin{figure}[ht]
        \centering
                \includegraphics[width=0.8\textwidth]{misc/erdapfel_prototype_settings.eps}
        \caption{Prototip pantalla de configuració d'erdapfel.}\label{fig-erdapfel_prototype_settings}
\end{figure}

\section{Funcionalitats de la façana de mapes}

La façana de mapes de SL4A havia de ser una abstracció a molt alt nivell del que podia fer la biblioteca estesa de mapsforge.

\paragraph{}
La idea d'aquesta façana seria, per exemple, processar un fitxer KML des d'un script Python, i invocar tot seguit una funció com ``showMap(kml)'' que el mostri per pantalla.

\paragraph{}
Aquestes són les funcionalitats que es van definir en un començament:

\begin{itemize}
        \item Visualitzar un mapa de fonts osm i navegar sobre seu.
        \item Obrir un fitxer de mapa fora de línia .map, KML o GML
        \item Permetre Generar elements geomètrics (punts i polígons) sobre un mapa obert.
        \item Realitzar mesures aproximades de distàncies i àrees sobre el mapa obert. 
        \item Guardar els elements geomètrics generats en KML o GML.
\end{itemize}

\paragraph{}
Ara bé, a diferència de les invocacions a la API de google, que no comporten cap problema, ja que aquesta està distribuïda ``de fàbrica'' en tots els dispositius Android, la nostra biblioteca no està distribuïda amb el sistema Android per defecte.

\paragraph{}
Això implicava que no tan sols calia crear una façana en el servidor de SL4A sinó que aquesta façana havia de tenir com a dependència la biblioteca estesa de mapsforge.

\paragraph{}
Així que es va decidir aprofitar que les capacitats requerides de la façana eren força compatibles amb les d'erdapfel per fer servir el programa com a punt d'entrada de la façana.

\paragraph{}
Això, tot i que no és una solució òptima, facilitava molt la distribució i instal·lació de la biblioteca i no suposava una dramàtica inconveniència per als usuaris, ja que les dimensions de l'aplicació erdapfel no són gaire més grans que la de la biblioteca en sí (es tracta d'una mida aproximada de 500Kb).

\paragraph{}
I de moment es van considerar aquests avantatges més importants que els inconvenients.

\section{Arquitectura del sistema}

Partint de les explicacions anteriors, aquest és l'esquema conceptual dels diferents elements del sistema i com interactuen entre ells (\autoref{fig-arquitectura-sistema}).

Noteu que el port d'Osmosis es un element del sistema separat de la biblioteca estesa de mapsforge pròpiament dita (el port és el que en el diagrama es veu com a mapfileWriter4And).


\begin{figure}[ht]
  \centering
        \includegraphics[width=0.8\textwidth]{misc/arquitectura_sistema.eps}
  \caption{Arquitectura del sistema.}\label{fig-arquitectura-sistema}
\end{figure}

Com es pot comprovar, erdapfel, tot i que havia de ser inicialment una senzilla aplicació de prova, ha esdevingut el punt d'entrada a les biblioteques generades tant per a Zamia com per a la façana de SL4A.

\section{Treball comunitari: Integració del GML i KML amb mapsforge}
\hypertarget{espec-treball-comunitari}{}En aquest apartat s'explicarà una mica més a fons els motius concrets pels quals es va decidir provar d'integrar les modificacions GML i KML de la biblioteca mapsforge a aquest projecte, les conseqüències que això va aportar al disseny i a la implementació d'aquesta part del projecte. La valoració final d'aquesta experiència es podrà trobar més endavant a les conclusions.

Abans de començar a implementar el ``parser'' de GML/KML es va considerar la següent possibilitat:

\paragraph{}

Sabent que mapsforge intentava mostrar mapes de diferents orígens i tenia suport per a mapes offline, i ja que tal i com es pot observar\TODO{link} hi havien propostes de millora de mapsforge referents a un suport per KML acceptades però amb molt poca prioritat degut a restriccions de temps i de personal. 

I sabent també que aquesta part havia de ser implementada per tal d'assolir els objectius del present projecte, semblava una bona idea intentar treballar en equip amb ells.

\paragraph{}

Així que ens vam posar en contacte amb la comunitat de desenvolupament de mapsforge i se'ls va proposar de desenvolupar aquesta funcionalitat dintre de la seva mateixa biblioteca, i col·laborar així amb el projecte.

\paragraph{}

La comunitat de mapsforge va dir que sí, però amb reserves. La veritat és que no va ser una resposta gaire entusiasta (com es pot veure a l'\hyperlink{annex-email-list-mapsforge}{annex}). La seva proposta va ser que fes un ``branch'' independent de mapsforge en un repositori de versions extern, i implementés la meva proposta allà, i que si resultava satisfactòria pels seus estàndards es faria una fusió d'aquesta ``branch'' amb la versió principal de mapsforge.

\paragraph{}

Així que, en un intent de contribuir a la comunitat de codi lliure, aquesta part del projecte s'ha intentat realitzar en màxima sintonia amb aquesta comunitat, utilitzant les eines i seguint les convencions que ells proposen (que d'altra banda són força raonables).

\paragraph{}

A continuació les esmento:

\subsection{Mapsforge conventions}

Les convencions del projecte mapsforge pel que fa al codi, en realitat estan basades gairebé completament en les convencions oficials del llenguatge de programació Java.

A més d'aquestes convencions hi ha una serie de normes definides per als membres del projecte.

\paragraph{}
Respecte a l'idioma i a la codificació dels caràcters.

El projecte fa servir tan sols anglès. Per tant tots els noms de paquets, arxius, mètodes, variables, així com també els comentaris i els missatges de les revisions han d'estar en anglès.

Per tal de no incorporar errors ortogràfics al projecte cal passar un corrector automàtic al codi (ells proposen el que està integrat amb l'Eclipse).

També demanen fer servir codificació UTF-8 i salts de línia de Unix ('\verb|\n|') per a tots els fitxers de font, comentaris i altra documentació escrita.

\paragraph{}
Per pujar versions al subversion (repository) cada ``commit'' ha de tenir un comentari adient esmentant totes les modificacions. I sempre que sia possible, tots els canvis que estiguin conceptualment relacionats entre ells hauries de ser pujats conjuntament.

\paragraph{}
Com a convencions específiques de Java sol·liciten que es treballi amb l'IDE (Integrated Development Environment) Eclipse i un formatejador de codi que està contingut en ell. A tal efecte proveeixen un perfil creat pel formatejador de codi (que demanen que no sigui modificat per als usuaris sense la aprovació dels membres del projecte), i demanen que aquest perfil s'apliqui al codi abans de fer qualsevol registre al supositori de svn.

\paragraph{}
A part demanen fer servir les bones pràctiques de programació de mantenir la visibilitat de les classes i mètodes al mínim. i fer servir el modificador ``public'' només quan sigui estrictament necessari.

\paragraph{}
També consideren que documentar el projecte utilitzant Javadoc és primordial. Per això demanen que totes les classes, mètodes i camps tinguin el seu comentari de Javadoc apropiat. Concretament aquests comentaris han de documentar (en el cas dels mètodes) tots els paràmetres i el valor de retorn. Naturalment també demanen que quan es realitzi qualsevol modificació a un mètode ja documentat s'actualitzi el comentari degudament.

\paragraph{}
Respecte als senyals d'avís del compilador (Warnings), i tenint en consideració que molts dels errors més usuals de programació poden ser evitats utilitzant els esmentats avisos, es demana que habilitem tots els avisos que garanteixin un elevat nivell de qualitat de software. 

També demanen que els warnings siguin resolts preferiblement pels desenvolupadors que els han generat, i que en cap cas s'utilitzin ``trucs'' per evitar els warnings (fer servir les anotacions de Java @SupressWarnings) o es modifiqui la configuració del compilador a tal efecte.

\paragraph{}
Naturalment també demanen que mai es pugi una versió amb errors de compilació al subversion.

\subsubsection{CheckStyle}

Checkstyle és una eina de desenvolupament per ajudar als programadors a escriure codi Java que compleixi els requisits d'un estàndard de codi. Automatitza el procés de comprovar el codi de Java per evitar que els desenvolupadors hagin de realitzar una tasca tant empipadors (però important). Això fa que sigui una eina ideal per a projectes que vulguin forçar l'aplicació d'unes convencions pel redactat del codi (és a dir un estàndard de codi).

\paragraph{}
Checkstyle és molt configurable i pot ser emprat per forçar l'aplicació de gairebé qualsevol estàndard de codi imaginable. L'estàndard que empra el projecte mapsforge és una petita variació de les convencions de Sun per a Java.

\paragraph{}
Això, a nivell del programador implica que després d'escriure una part de codi, cal executar el CheckStyle i comprovar els avisos que genera. Una de les maneres més pràctiques de realitzar aquest procés és instal·lar un ``plug-in'' per eclipse que existeix i que integra CheckStyle a l'entorn de desenvolupament. Però també es podria fer des de línia de comandes, o fent servir eines com l'ant, etc. Els ``errors'' que mostra checkstyle poden ser tant de disposició del codi com de problemes de disseny, duplicitat de codi, o mala aplicació de patrons.

\paragraph{}
Aquí podeu trobar més informació\cite{bib-checkstyle}.


\subsubsection{FindBugs}

FindBugs™ és un programa per trobar errors (bugs) en programes Java. Es dedica a cercar instàncies de ``patrons d'error'', és a dir, patrons en el codi que probablement indueixin a la aparició de bugs.

\paragraph{}
De forma similar a CheckStyle existeix un plug-in per a eclipse que en facilita l'execució. 

\paragraph{}
Aquí podeu trobar més informació\cite{bib-findbugs}.

\subsubsection{PMD}

PMD busca potencials problemes o pràctiques de programació que considera inadequades en el codi font Java, com ara:

\begin{enumerate}
        \item Possibles bugs, sentències try/catch/finally/switch buides.
        \item Codi mort, variables locals o paràmetres no usats, o mètodes inservibles.
        \item Codi no optim, Cadenes de caràcters ``malgastades''.
        \item Expressions massa complicades, sentències ``if'' innecessàries, sentències for que podrien ser whiles
        \item Codi duplicat, fragments de codi que podrien ser ``factoritzats''
\end{enumerate}

Com es pot veure la funció d'aquest programa és força similar a la de l'anterior. Suposo que la redundància deu tenir alguna raó de ser i ambdós programes són complementaris, la veritat és que els errors que PMD detecta solen ser més ``paraniocs'' que el de FindBugs, però com que era un requeriment ``ineludible'' de mapsforge tampoc s'ha investigat molt en aquest sentit.

\paragraph{}
Les sigles PMD no tenen cap significat concret, segons els seus creadors:

\subsubsection{JUnit Tests}

JUnit és una biblioteca per realitzar ``tests'' automatitzats sobre classes Java.

\paragraph{}
Un ``test unitari'' és un mètode per provar fragments de codi font de manera individual per determinar si responen com és previst.

\paragraph{}
En el cas concret de les classes que hereten d'Android, però, els testos mitjançant JUnit es compliquen, ja que no es poden automatitzar sense fer servir el ``framework'' de JUnit específic d'Android (Android Test framework), que té components específics per provar classes relacionades amb el framework d'Android (que d'altra manera, i fent servir els mòduls de JUnit convencionals, fallarien).

\paragraph{}
El cas és, però, que el projecte mapsforge no proporcionava ``tests'' o proves per a cap classe que heretes d'Android, i només realitzava proves sobre les classes Java Bàsiques fent servir la implementació de JUnit ``estàndard''.

\paragraph{}
Així que vaig seguir la mateixa política, i no es van dissenyar ``tests'' per a cap classe que heretes d'Android.

Per a més informació consulteu\cite{bib-junit}.

\subsection{Deliveracions sobre la implementació dels Parsers}

Una de les primeres qüestions que vaig plantejar a la comunitat (mitjançant un debat del grup de desenvolupadors), va ser que aclaríssim quin mètode faríem servir per parsejar els fitxers. 

\paragraph{}
Hi ha moltes més maneres de parsejar un XML de les que semblen a primera vista, i en el cas que ens ocupa vaig pensar que calia tenir-ho molt present, ja que al desenvolupar per a un dispositiu mòbil, les limitacions, sobretot de memòria semblava que podien resultar d'una incidència important, però a més també calia valorar de no sobrecarregar el projecte amb moltes biblioteques externes, ja que el sistema que triés quedaria inclòs a mapsforge com a una nova dependència. Per això volia saber l'opinió de la comunitat.

\paragraph{}
Les dos principals maneres de parsejar i crear XML's proposades per W3C (que poden ser considerades estàndards), que són DOM i SAX.

%això ha de ser un itemize?

\subsubsection{DOM} Es tracta de carregar tot el document en memòria i analitzar-lo per crear un objecte amb estructura d'arbre que pot ser accedit pel programa. En entorns amb molta memòria disponible aquest pot ser un mètode pràctic, però tenint en compte les limitacions de memòria dels dispositius Android, i la mida d'alguns fitxers GML o KML, es va pensar que no seria el sistema més adient.

\subsubsection{SAX} En aquest cas, es tracta d'un parser ``event-driven''. Que no carrega el fitxer en memòria ni proporciona accés a un objecte estructurat amb tota la informació, sinó que cerca informació concreta i crida a determinades funcions al trobar-la. El consum de memòria d'aquest parser doncs és molt menor que la d'un DOM, però com a contrapartida cal estructurar les dades ``manualment''.

\paragraph{}
A partir d'aquí altres alternatives que s'han valorat han estat majoritàriament implementacions del que es coneix com a XML bindings (concretament Java-to-XML bindings). 

\paragraph{}
Essencialment són procediments per representar els documents XML com a Objectes, en aquest cas objectes de Java directament.


Segons proposa Donny Hallman\TODO{citation} utilitzant aquests procediments es pot millorar el processament de GML (i també KML).

Existeixen moltes implementacións d'aquest mètodes, de les quals s'ha valorat la anomenada JiBX.

\subsubsection{JiBX\cite{bib-jibx}}

Tal i com es menciona a aquest blog\cite{bib-xml-binding}, JiBX planteja una proposta aparentment excel·lent per a vincular dades XML a objectes Java sobre la plataforma Android. 

Ja que és ràpida, lleugera i amb un impacte reduït en el projecte actual (només cal afegir uns 60KB addicionals a l'aplicació), fa servir l'XMLPull parser d'Android per defecte i és teòricament fàcil i còmode d'utilitzar.

\paragraph{}
Així que amb les atractives expectatives es va decidir fer una prova de la utilització d'aquesta biblioteca, i trobant la prova satisfactòria, acabar implementant la solució amb JiBX.

\paragraph{}
Es per això que més endavant es detallarà més aquesta biblioteca i la seva filosofia.

\section{Conclusió}

Com es pot veure el disseny global d'aquest projecte és complex. Això és fruit, suposo, de que és un projecte força heterogeni, i cadascuna de les parts que el conformen ha condicionat d'alguna forma el resultat final. Així doncs el disseny ha estat molt condicionat per elements externs i l'elecció de les tecnologies a fer servir. I les decisions de disseny que s'han pres han estat sempre per intentar mantenir el més simple possible la interacció entre les parts del sistema. 

En termes generals s'ha intentat respectar la filosofia de cada un dels elements a integrar, així, per posar un exemple, per la comunicació dintre d'Android s'ha preferit la utilització d'Intents abans que d'altres alternatives ja que aquesta és ``la manera de fer d'Android''.

Per aconseguir això ha calgut documentar-se i entendre bé cadascuna de les solucions triades, i en algunes ocasions això ha resultat complicat degut a la manca de documentació a molt alt nivell d'alguns d'aquests projectes.

\paragraph{}
Així podríem concloure que la part fonamental d'aquest projecte ha estat la integració de sistemes.
